前言

昨天我們講pub-sub模式的核心概念、流程與優點，讓大家對pub-sub有個基本的理解，但方法有優點就會有缺點，今天我們會用範例說明pub-sub並列舉出它的缺點。

好了～我們開始吧!

Pub-Sub

前一篇的文章裡我們談到pub-sub是由publisher、subscriber以及event broker組成的，也有講每個角色各自負責的職責。

但沒舉例感覺有點抽象，不是很理解，讓我們用電商平台為範例:

當使用者看到訂了某個商品並結帳，此時訂單系統(publisher)會發送一條訊息到event broker，請它通知有subscribe的subscriber(結帳系統、物流系統)，subscriber收到event後會進行相對應的處理，像是結帳系統負責處理結帳、像銀行申請扣款，物流系統負責出貨相關操作，彼此不用互相等待，可以獨立處理。

等到這兩個subscriber的操作都完成並回傳完成的訊息，請event broker通知publisher處理完畢，可以進行下一項任務，publisher就會傳送下一個event給event broker，請有訂閱這個event的subscriber(通知系統)處理通知user的操作。

這樣的設計模式可以確保各系統間的協調運作，能獨立完成手上的工作，而不是卡在那邊乾等。

Pub-Sub缺點

但一個模式有優點就會有缺點，我們列舉pub-sub的幾個缺點:

• 複雜性提升：系統的架構變得很複雜，需要額外的event broker管理訊息和event，這增加開發和維護的難度
• 調試困難：系統中的不同conponent間是解耦合(decoupling)，當其中一邊出現問題，追蹤和排查問題可能會變得麻煩
• 訊息遺失：在某些情況下，訊息可能因系統出錯而遺失，特別是在訊息沒有持久化的情況下，這點我們後續的event broker系列會細講

總結

Pub-Sub模式在許多應用提供了很高的靈活性和擴展性，能夠有效提升系統的性能。可惜的是，它的複雜度和潛在的問題需要團隊在設計的時候需要仔細的衡量。之後會透過event broker的系列講pub-sub延伸的功能。

好了～今天就到這邊!!

Reference

-系統設計入門：Pub/Sub Pattern